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“| cannot conceive of any vital disaster These tutorials are a simplified 
f / introduction, and are not sufficient on 
happening to this vessel. Modern their own to achieve system safety. 
shipbuilding has gone beyond that.” You are responsible for the safety of 
your system. 


—- EJS Smith (Captain of the RMS Titanic) © 2020 Philip Koopman 1 


E Carnegie 
Safety Requirements Mellon 


University 


= Anti-Patterns for Safety Requirements: 
e No specifically identified safety requirements 
e All functional requirements are safety critical 





e Safety requirements can't be validated 


=m Specifying safety: 
e Safety goals: “working” is not the same as “safe” 
— How hazards are avoided at system level | 
— Can involve correctness, backup systems, failsafes, ... ‘ 


- Often what the system does not dois as important as what it does 
e Safety requirements: 





—- More detailed safety-specific requirements allocated to subsystems 
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Identifying Safety-Related Requirements —s tee"... 


= Overly-simplistic approach: 
e Start with system requirements 
e Annotate critical system requirements 
e Then, annotate supporting requirements 


e Problem: 
Most requirements can become critical 


= Too many system components 
promoted to highest criticality level 


e Allocating even one critical requirement 
to component makes whole thing critical 


Requirement Annotation Approach: 


RO1. Lorem ipsum dolor sit amet, consectetur adipiscing elit. 

R02. Nam suscipit odio aliquam massa finibus, id imperdiet. 
RO3. Quisque vehicula quam ut dui venenatis varius. 

R04. Nulla posuere diam ac augue bibendum, vitae laoreet. 

RO5. Pellentesque aliquam sem sit amet justo porttitor. 

R06. Vestibulum scelerisque lacus ac neque volutpat, dictum. 
RO7. Ut venenatis ante in ligula efficitur, congue posuere. 
RO8. Nam a nulla ultrices, tempor quam et, fringilla nisl. 

RO9. Vestibulum a arcu interdum, placerat eros non, ultrices. 
R10. Ut commodo odio eu elit porttitor facilisis. 

R11. Etiam et sem eu eros congue sollicitudin. 

R12. Proin tincidunt arcu quis dui tristique volutpat. 

R13. Fusce quis magna aliquet, venenatis sem ac, rhoncus. 
R14. Cras vel nulla eget orci semper varius scelerisque tellus. 
R15. Cras mollis lorem vitae libero sollicitudin lobortis. 

R16. Vestibulum luctus nisi ac nibh varius congue. 

R17. Maecenas consequat augue eu venenatis euismod. 
R18. Quisque viverra felis in est ornare consectetur. 
R19. Cras pellentesque turpis sit amet justo scelerisque. 
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Safety Envelope Requirements Approach —tiiwr.,, 


= Safety Envelope: oprt STATE, SP 
e Specify unsafe regions for safety Rs FAILSAFE acrwareD 
e Specify safe regions for functionality 
— Deal with complex boundary via: 









~~ 
\e 





upon transition to unsafe region 
= Partition the requirements: 
e Operation: functional requirements 
@ ® e  —_— — 
e Failsafe: safety requirements (safety functions) poe ROCA a 


» Under-approximate safe region 2 SAFE 
(reduces permissiveness) | 2 OPERATIONAL 
» Over-approximate unsafe region “\ STATE SPACE 
e Trigger system safety response | a | 
‘= 


i 


_ FAILSAFE ACTIVATE D- 
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Architecting A Safety Envelope System leh, 
= “Doer’ subsystem Doer/Checker Pair 






e Implements normal functionality 
e Allocate functional requirements to Doer 


Low SIL 


” OUTPUTS 


SAFETY *: 
SHUTDOWN : 


m “Checker” subsystem 
e Implements failsafes (safety functions) 


REDUNDANT INPUTS 


e Allocate safety requirements to Checker aha 

} . ’ Safety 
= Checker is entirely responsible for safety sae 
Checker 


e Doer can be at low SIL (failure is lack of availability) 
e Checker must be at high SIL (failure is unsafe) 


— Often, Checker can be much simpler than Doer 
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Safety Requirements Best Practices a 
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| 2 D-RO1. Lorem ipsum dolor sit amet, consectetur adipiscing elit. 
= Doer/Checker pattern G Dats dunn vel um divers vann 
e Functional requirements allocated to low-SIL Doer 9 D-ROS. Pellentesque aliquam sem sit amet justo porttitor. : 
: : 1B p-n07) Uficnenatisientsinllgila officitir, Wongualpdeietas 
© Safety requirements allocated to high-SIL Checker a ais ait fr ai fringilla nisl. 
& D-RO9. Vestibulum a arcu interdum, placerat eros non, ultrices. 
. D D-R10. Ut commodo odio eu elit porttitor facilisis. 
= Good safety requirements ee ae 
Low SIL 
e Trace to system-level safety goals 5 
— Orthogonal to normal functional operation if possible =< : 
° ° ° = SAFETY “= GURPURS 
e Make safety simple to validate (test, peer review) & suuTDOWN: 
0 . 
- Safety testing mostly exercises the Checker box 0 ae 
cS A 
| Seman High SIL 
= Pitfalls: 5a 
S > C-RO1. Et sem eu eros congue sollicitudin 
© Tradeoff between simplicity and permissiveness = a C-RO2. Tincidunt arcu aug tristique volutpat. 
© @ C-RO03. Quis magna aliquet, venenatis sem ac, rhoncus. 


— Doer optimality costs Checker validation effort 


e Fail-operational functions may require multiple Doer/Checker pairs 
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MY CUBESAT PROPOSAL VAS THE FIRST TO BE REJECTED FOR 
VIOLATING EVERY DESIGN AND SAFETY REQUIREMENT SIMULTANEOUSLY: https://xked.com/1992/ 


